LAYER 1: EXECUTIVE CONTEXT (Cody's Notes)

LAYER 2: CORE PHILOSOPHY (The Narrative Summary)

Core Philosophy

"Mercenaries" build what they are told to build; "Missionaries" are true believers in the vision and are empowered to solve problems. Missionaries are more productive, creative, and committed because they have a sense of ownership.

1. Empowerment and Context

• Deep Context: Missionaries need deep context on the customer and the business strategy to make informed decisions and feel invested.
• Problem-Based Assignments: Move from "output-based" instructions to "problem-based" assignments, giving the team autonomy over the "how."

2. The Product Trio in Discovery

• Direct Exposure: Ensure the Product Manager, Designer, and Lead Engineer are all involved in discovery from day one.
• Empathy for Pain: When engineers see the customer's pain firsthand in interviews, they shift from mercenaries to missionaries.

Quick Reference Checklist

• Does every team member know exactly which customer problem they are solving?
• Are engineers involved in customer interviews and discovery sessions?
• Is the team evaluated on the impact of their work rather than the volume of code?
• Do we have a shared, inspiring product vision that the team actually believes in?

Generated for the Product Leadership Growth Program.

LAYER 3: FULL REFERENCE (Raw Article Content)

Source: Missionaries vs. Mercenaries

One of my all-time favorite quotes in our industry comes by way of the legendary VC, John Doerr, where he argues that “we need teams of missionaries, not teams of mercenaries.” This point captures so much, and gets right to the heart of the most important trait of strong leaders, strong organizations, and strong product teams.

This is not hard to spot, either way.  Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.

In my experience with product teams, there’s simply no comparison between the morale, speed and most importantly, the results, of a team of missionaries as compared with a team of mercenaries.

So why don’t more companies get this?  There are typically three main reasons I see:

1. Leadership.  So many executives and stakeholders think they know the answers, and they really don’t even want to discuss or debate it.  They just want a team that will follow their directions.  These same leaders usually complain to me that the team moves too slowly, and that unless they spell out every little detail the team gets it wrong, and in any case they rarely blame themselves for the poor results.

2. Staffing.  Some leaders absolutely get the importance of a team of missionaries, but they have inherited an organization that is staffed by people that are resigned to the mercenary model.  A variation of this is when the organization has significant outsourcing of the designers or engineers that are on the teams.  It’s nearly impossible to have a team of missionaries when your engineers work for another company and are under contract to build what you tell them to.  That’s pretty much the definition of a mercenary.  And it leads to epic waste.

3. Process.  Several product development processes out there, especially those that claim to be designed for “the enterprise,” are predicated on the mercenary model.  Now none of them would ever describe themselves that way, but that’s very much what I argue is going on.  For example, a few people have asked me about SAFe (Scaled Agile Framework).  I always tell them that what I know of SAFe is all second-hand because I literally don’t know of a single strong product company that uses it.  But from everything I have heard and read about it, I have a hard time imagining a worse model for true, technology-powered product companies that depend on a stream of consistent innovation.  In contrast, the Spotify model of scaling Agile is much more in line with what I advocate, and I would argue theirs is predicated on the missionary model.  More on this topic in upcoming articles.

The three issues above are not mutually exclusive.  In fact, over time one usually leads to the others.  And when the objective is to transform an organization to best practices, these are among the most critical yet toughest parts of that transition.

So how do you change?

It begins with those same three areas:

First, we need to educate the leadership team.

Second, we need to raise the bar on the staff – starting with product managers but also product designers and at least the senior engineers / tech leads.  If the company isn’t set up this way already, then it’s critical to move aggressively to durable, cross-functional, co-located (whenever possible) product teams (“squads” in Spotify lingo).

Finally, it’s about adopting the processes and techniques that allow teams to show what they can do.  There’s quite a bit here but it starts with a compelling product vision combined with business outcomes (objectives with measurable key results) for the organization and for each product team.

If your organization is acting a lot more like teams of mercenaries rather than missionaries, then I hope you’ll consider seriously why this might be the case, and whether your organization has the capability and the will to turn this around.

Generated for the Product Leadership Growth Program.